Subject: Names in ACTPU/ACTLU

From: Brian Jewell <[email-masked]>
Date: Wed, 20 Dec 1995 11:00:45 -0800 (PST)

Some more input on PU/LU names in SNA...specifically on using NMVTs
to transport the names:

There are positive and negative sides to this suggestion that 
haven't been mentioned.

Positive: IBM's main concern with the issue of sending PU/LU names
seems to lie with 'breaking' older PU implementations by changing 
the format of either the XID or the ACTPU/LU. This argument breaks 
down somewhat if NMVTs are used to transport names, as PU 
implementations have been dealing with NMVTs for a lot of years now 
and have (in thoery) learned to reject the ones are not supported 
(case in point: RUNCMDs and RTM NMVTs).  Hence creating a new NMVT 
to carry PU/LU names should have little effect on existing PU 
implementations which should just reject them with a -RSP and the 
appropriate sense code as outlined in the SNAMS Reference Manual 
(SC30-3346).

Negative: To my knowledge, the sending of NMVTs is a higher-layer
function, not normally performed by VTAM, but instead by VTAM 
applications, such as NetView. Hence implementation of this approach
might actually lie outside the realm of VTAM...and having it only
work on hosts with NetView installed would remove much of the
value.

So to get to the point: the concept of using NMVTs for transporting 
PU/LU names shouldn't be discarded just yet. Because it does offer a
viable alternative for transporting the information in a relatively 
seemless way which is likely to have less of an impact on legacy
equipment than changing the format of ACTPU/ACTLU - 
unless IBM has failed to follow their own architecture, and I 
know that would never happen ;-)

Brian Jewell
3Com, Inc.

Original text follows:

--------------------------------------------------------------------

Dave originally wrote:

> Better yet, I think I've got a much better solution!  How about if
> we allow the PU to request its name on RSP(ACTPU)?  This in-turn
> would imply a request for LUnames on subsequent ACTLU.  We can find
> bits as necessary in RSP(ACTPU) format 1.  And we'd have to create a
> new RU or NMVT to send the PU name on.  This would only impact VTAM
> (instead of VTAM and NCP).  New PU code could support this option if
> desirable, and spoofing devices (DLSw, FRADs, PU2 Gateways, etc.)
> could easily snoop the SSCP-PU sessions for this traffic.

Derek replied:

>>Yes, that's not bad.  Strictly speaking it wouldn't require a new NMVT
>>- VTAM could merely resend the ACTPU but with the PU name wrapped in a
>>vector NCP won't look at (in addition to the one that will be
>>stripped).  VTAM would need to remember that it had done this, not
>>only to avoid repeating the cycle on the next RSP(ACTPU) but also to
>>add a second copy of the LU name to the ACTLUs.

>>You say that using a separate NMVT has the advantage of no NCP change,
>>but to keep that advantage the same technique would have to be used
>>for the LU names.  Is that getting a bit messy?